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(54) Network communication 

(57) An electronic network system for implementing 
ARP (Address Resolution Protocol) and RARP (Re- 
verse Address Resolution Protocol) type communica- 
tion. ARP type communication is facilitated by including 
within the ARP response packet an offset address indi- 



cating the memory location of the software application 
that is the subject of the ARP type communication. 
RARP type communication is facilitated by providing 
each network node with a network unique ID and using 
the unique ID when generating RARP requests. 
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Description 

This invention relates to an apparatus for, and a 
method of, communicating over a network. 

There are many well known protocols for imple- 5 
menting electronic communication in a network. Two 
such protocols are the Address Resolution Protocol 
(ARP) and the Reverse Address Resolution Protocol 
(RARP). The ARP and RARP protocols may be used, 
for example, to implement communications in a network io 
that includes two or more network nodes connected via 
an electronic bus. An illustrative network is shown in Fig. 
1. 

As can be seen from Fig. 1 , transmissions directed 
from a first general purpose computer 2 to a second gen- is 
eral purpose computer 4 are indicated by an arrow 6. 
Similarly, communications directed from the second 
computer to the first computer are indicated by an arrow 
8. It should be understood that an electronic bus, such 
as an I EEE-1 394 serial bus, interconnects computers 2 20 
and 4, and is used to channel transmissions between 
the computers. The transmissions are abstractly repre- 
sented by arrows 6 and 8. Furthermore, it should be un- 
derstood that although Fig. 1 shows only two computers, 
the network represented in Fig. 1 may be made up of 25 
more than two computers. Fig. 1 is referenced below for 
purposes of describing ARP and RARP communication 
in more detail. 

ARP may be used when a first network computer 
wishes to communicate with a second network compu- 30 
ter but does not know the second computer's physical 
address. For example, computer 2 may wish to commu- 
nicate with computer 4 but has only computer 4's inter- 
net protocol address (or "IP address") and not computer 
4's physical address. In accordance with ARP, computer 35 
2 broadcasts an "ARP request" (represented by arrow 
6) over the network bus. The request includes the IP 
address of computer 4. By examining the IP address of 
the request, computer 4 recognizes that it is the intend- 
ed recipient of the request. Computer 4 then transmits 40 
an "ARP response" (represented by arrow 8), which is 
addressed to computer 2 and contains computer 4's 
physical address. 

RARP may be used when a network computer wish- 
es to determine its IP address through the network. For 45 
example, computer 2, wishing to determine its IP ad- 
dress, broadcasts a "RARP request" (represented by ar- 
row 6) over the network. The RARP request includes 
the IP address of computer 4, as well as the physical 
address of computer 2. After computer 4 ascertains that 50 
it is the intended recipient of the RARP request - through 
examination of the IP address - it determines the IP ad- 
dress of computer 2 by cross-referencing computer 2's 
physical address to computer 2's IP address and then 
transmits a "RARP response" (represented by arrow 8), 55 
which includes the IP address of computer 2. 

Both ARP and RARP have drawbacks which limit 
their effectiveness. In ARP, a requesting node is limited 



to acquiring the physical address of a target node, and 
cannot acquire information that would facilitate commu- 
nication between itself and the target node. In particular, 
the requesting node cannot acquire the address within 
the target computer of the application which is the sub- 
ject of the request. Thus, in Fig. 1 for example, once 
computer 2 determines the physical address of compu- 
ter 4, communication between the two computers may 
proceed, but each time computer 4 receives a commu- 
nication packet from computer 2, computer 4's process- 
ing unit (CPU) must examine the received packet and 
then forward the packet to an appropriate application 
within its memory. Moreover, the size of the communi- 
cation packets is limited in ARP, further limiting flexibility. 

A drawback of RARP is its sensitivity to bus resets. 
When a network bus is reset - such as when the power 
supply is toggled, or a new device is connected to the 
network - the physical addresses of the network nodes 
may change, resulting in the generation of incorrect 
cross-references by nodes generating RARP respons- 
es. Thereby, resulting in the transmission of incorrect IP 
addresses to requesting nodes. 

Some aspects of the invention are specified in the 
claims to which attention is invited. 

An embodiment of the present invention seeks to 
provide a network communication system wherein ARP 
type communication is facilitated by providing nodes 
that generate ARP requests with additional information 
about responding nodes and by allowing for variable 
length ARP communication packets. 

A further embodiment of the present invention 
seeks to provide a network communication system 
wherein RARP type communication is facilitated by re- 
ducing the network's sensitivity to bus resets. 

In accordance with an embodiment of the invention, 
when an ARP type communication session is initiated 
through request and response packets, the response 
packet includes an offset address specifying the loca- 
tion of the software application that is the subject of the 
session. Thereby, allowing session packets subsequent 
to the response packet to be addressed directly to the 
application, and allowing those subsequent packets to 
be of variable size. Furthermore, each network node is 
assigned a node unique ID for the purpose of providing 
an unchanging identifier for each node. Thereby, provid- 
ing an unchanging physical address reference for use 
in RARP type requests, and allowing RARP type com- 
munication to be conducted without interference from 
network resets. 

The following detailed description, given by way of 
example and not intended to limit the present invention 
solely thereto, will best be appreciated in conjunction 
with the accompanying drawings, wherein like reference 
numerals denote like elements and parts, in which: 

Fig. 1 is a schematic diagram of an electronic net- 
work useful in describing ARP type and RARP type com- 
munications. 

Fig. 2 is a schematic diagram of an electronic net- 
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work in accordance with the invention. 

Fig. 3 is a representation of an address cache table 
in accordance with the invention. 

Fig. 4 is a representation of an ARP type request 
packet in accordance with the invention. 

Fig. 5 is a representation of an ARP type response 
packet in accordance with the invention. 

Fig. 6 is a representation of a RARP type request 
packet in accordance with the invention. 

Fig. 7 is a representation of a RARP type response 
packet in accordance with the invention. 

Fig. 2 shows an illustrative electronic network in 
which embodiments of the present invention may be 
employed. As can be seen from the figure, the network 
includes two buses, bus 24 and bus 26, that are coupled 
together via a bridge 28. Bus 24 is coupled to three 
nodes, nodes 10, 12 and 14, and bus 26 is coupled to 
four nodes, nodes 16, 18, 20 and 22. For purposes of 
illustration, each node of Fig. 2 is considered to be a 
general purpose computer, buses 24 and 26 are consid- 
ered to be IEEE-1394 buses, and the bridge is consid- 
ered to be an IEEE-1394 bridge - although in view of 
this disclosure it will be apparent that many types of 
nodes, buses, and bridges are suitable for implementing 
the invention. 

In any event, the buses and nodes of Fig. 2 are as- 
signed identification numbers (IDs). Buses 24 and 26 
are referred to as buses "O" and "1 °, respectively. Nodes 
10,12 and 1 4 are referred to as nodes °Q U , 0 1 n and "2", 
respectively, and nodes 16, 18, 20 and 22 are referred 
to as nodes "0", "1", "2° and "3", respectively - any two 
nodes having the same ID being distinguished by the 
busses to which they are coupled. In addition, each of 
nodes 10-22 is assigned a node unique ID which is suf- 
ficient to uniquely identify each node without referring 
to bus IDs and/or node IDs. The bus IDs, node IDs and 
node unique IDs are stored in an address cache table 
along with the node IP addresses. Preferably, a copy of 
the address cache table is stored within each network 
node. 

An exemplary address cache table corresponding 
to the network of Fig. 2 is shown in Fig. 3. One way in 
which each of the network nodes may acquire the ad- 
dress cache table is through ARP type signaling. That 
is, in the course of conducting an ARP type session, a 
responding node may send the requesting node its bus 
ID, node ID, node unique ID, and IP address, which the 
requesting node then stores in its address cache table. 
Of course, at any given time the requesting node's table 
may or may not contain updated information for all 
nodes in the network. 

Having described an illustrative network configura- 
tion and an illustrative address cache table, ARP type 
and RARP type communication in accordance with em- 
bodiments of the invention will now be described in de- 
tail. 

Figs. 4 and 5 show illustrative ARP type communi- 
cation packets in accordance with the invention. Fig. 4 



shows an ARP type request packet, and Fig. 5 shows 
an ARP type response packet. As shown in the figures, 
the ARP request and response packets are asynchro- 
nous packets. Each packet includes five primary divi- 
s sions: an asynchronous packet header 30, a stream 
type 32, a Logical Link Control/SNAP (LLC/SNAP) 
header 34, an ARP/RARP header 36, and ARP/RARP 
data 38. Each of the primary divisions are, in turn, divid- 
ed into one or more horizontal subdivisions having a 
to length of four bytes each. 

Referring to the ARP request packet of Fig. 4, it can 
be seen that the first item included in the asynchronous 
packet header is a broadcast bus indicator (e.g. 10 bits 
representing the string 0x3FE) for indicating which bus 
is or buses in the network should receive the request pack- 
et (e.g. all - buses 0 and 1 ). The next item is a broadcast 
node indicator (e.g. 6 bits representing the string 0x3F) 
for indicating which node or nodes in the network should 
receive the request (e.g. all - nodes 10-22). After the 
broadcast node indicator is a source ID which is the 
node I D of the node that transmits the request. Following 
the source ID is a destination offset (e.g. 6 bytes repre- 
senting the string OxFFFF FFFF FFFF) for indicating a 
location within the memory of intended recipient node 
where the request should be directed. 

The stream type (ST) division includes a communi- 
cation type indicator (e.g. bits representing the string 
0x00) for indicating the type of communication to which 
the request packet is related (e.g. Logical Link Control 
- ARP/RARP/IP). 

The LLC/SNAP header division includes a resolu- 
tion protocol indicator (e.g. bits representing the string 
0x0806) for indicating the type of protocol to which the 
request packet is related (i.e. ARP). 

The ARP header division includes a protocol type 
indicator and an operation indicator. The protocol type 
indicator contains information (e.g. bits representing the 
string 0x0800) for indicating the protocol to which the 
request packet is related (e.g. IP protocol). The opera- 
tion indicator contains information indicating the type of 
operation to which the packet is related (i.e. ARP re- 
quest). 

Finally, the ARP data division of the ARP request 
packet will be described. The first item included in the 
ARP data division is a transmitter address, indicating the 
address of the node that transmitted the ARP request 
packet. The transmitter address may be, for example, a 
64 bit address, with the first 16 bits indicating the node 
ID of the transmitting node and the following 48 bits in- 
dicating a requesting node offset address, the request- 
ing node offset address being an address within the 
transmitting node's memory where communication 
packets are processed (e.g. the address of an applica- 
tion program). The second item in the ARP data division 
is the node unique ID of the transmitting node (e.g. 64 
bits). The third item is the IP address of the transmitting 
node (e.g. 32 bits), and the fourth item is the IP address 
(e.g. 32 bits) of the node that is the intended recipient 
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of the request packet. 

As an option, the ARP data division may include ar- 
eas for a destination address and a node unique ID of 
the destination node. These areas are analogous to 
those provided for the transmitter address and the node 
unique ID of the transmitting node, respectively. How- 
ever, since the request packet is broadcast, the desti- 
nation areas are indefinite, and therefore are not filled 
with actual addresses. In an exemplary embodiment, 
the destination address and destination unique ID areas 
are 64 bit areas that are filled with zeros to indicate their 
indefinite state. 

As an additional option, error checking bit(s) may 
be included within the request packet. These bits may 
be for detecting and/or correcting errors within the pack- 
et through implementation of an error checking code, 
such as a cyclic redundancy code (CRC). Moreover, 
multiple groups of error checking bits may be included 
within the packet, with each group dedicated to detect- 
ing and/or correcting errors within a distinct portion of 
the packet. Thus, for example, the ARP header division 
may include a first group of dedicated error checking bits 
for use in detecting and/or correcting errors in the head- 
er division's contents, while the ARP data division may 
include a second group of dedicated error checking bits 
for use in detecting and/or correcting errors in the data 
division's contents. 

The ARP response packet will now be described 
with reference to Fig. 5. It can be seen from Fig. 5 that 
the first item included in the asynchronous packet head- 
er is a transmitter node I D (e. g. 1 6 bits) which is the node 
ID of the node that transmitted the ARP request packet 
prompting the response. The next item is a response 
source ID (e.g. 16 bits) which is the node ID of the node 
transmitting the response packet. Following the re- 
sponse source ID is a response destination offset (e.g. 
6 bytes) which indicates the location within the memory 
of the responding node where the protocol specified by 
the "protocol type" indicator is processed. 

The stream type (ST), LLC/SNAP header, and ARP 
header divisions of the response packet are similar to 
the ST, LLC/SNAP header, and ARP header divisions 
of the request packet. The ST division of the response 
packet includes a communication type indicator (e.g. 
bits representing the string 0x00) for indicating the type 
of communication to which the request packet is related 
(e.g. Logical Link Control - ARP/RARP/IP). The LLC/ 
SNAP header division includes a resolution protocol in- 
dicator (e.g. bits representing the string 0x0806) for in- 
dicating the type of protocol to which the request packet 
is related (i.e. ARP). The ARP header division of the re- 
sponse packet includes a protocol type indicator and an 
operation indicator - the protocol type indicator contain- 
ing information (e.g. bits representing the string 0x0800) 
for indicating the protocol to which the response packet 
is related (e.g. IP protocol), and the operation indicator 
containing information indicating the type of operation 
to which the packet is related (i.e. ARP response). 



Finally, the ARP data division of the ARP response 
packet will be described. The first item included in the 
ARP data division is a response transmitter address, in- 
dicating the address of the node that transmitted the 
s ARP response packet. The response transmitter ad- 
dress may be, for example, a 64 bit address, with the 
first 16 bits indicating the node ID of the responding 
node and the following 48 bits indicating a responding 
node offset address, the responding node offset ad- 
dress being an address within the responding node's 
memory where communication packets are processed 
(e.g. the address of an application program). The sec- 
ond item in the ARP data division is the node unique ID 
of the response transmitting node (e.g. 64 bits). The 
third item is the IP address of the response transmitting 
node (e.g. 32 bits), and the fourth item is the IP address 
(e.g. 32 bits) of the node that is the intended recipient 
of the response packet. 

The ARP data division of the response packet fur- 
ther includes the address of the intended recipient of the 
response packet (i.e. the requesting node) and the node 
unique ID of the intended recipient. The format for these 
additional items may be analogous to the format for the 
request transmitter address and the request transmitter 
node unique ID, respectively. Thus, the responding 
node may simply use the first two items of the request 
packet's ARP data as the additional items in the re- 
sponse packet, thereby facilitating formation of the re- 
sponse packet. 

As was in the case the request packet, the response 
packet optionally includes error checking bit(s). These 
bits may be for detecting and/or correcting errors within 
the packet through implementation of an error checking 
code, such as a cyclic redundancy code (CRC). More- 
over, multiple groups of error checking bits may included 
within the packet, with each group dedicated to detect- 
ing and/or correcting errors within a distinct portion of 
the packet. Thus, for example, the ARP header division 
may include a first group of dedicated error checking bits 
for use in detecting and/or correcting errors in the head- 
er division's contents, while the ARP data division may 
include a second group of dedicated error checking bits 
for use in detecting and/or correcting errors in the data 
division's contents. 

Having described a network suitable for implement- 
ing the invention and ARP type packets in accordance 
with the invention, an illustrative ARP type communica- 
tion will now be described. 

In an illustrative ARP type communication accord- 
ing to the invention, node 0 on bus 0 (or "node 10' as 
indicated in Fig. 3) wants to know the physical address 
of the node having an IP address of 4 (or "node 18" as 
indicated by Figs. 2 and 3). Accordingly, node 10 broad- 
casts an ARP request packet having the format shown 
in Fig. 4 to all of the nodes in the network - the packet 
being transmitted to the nodes in bus 1 via the bridge 
(see Fig. 2). As mentioned above, the request packet 
includes a destination offset in the ARP header division. 
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and a destination IP address in the ARP data division. 
In the present illustration the ARP data includes a des- 
tination IP address of "4\ 

Upon reception of the broadcast request packet, 
each node in the network sends the ARP data of the s 
packet to the address indicated by the destination offset 
Each node then reviews the destination IP address in- 
dicated in the ARP data of the request, and if the desti- 
nation IP address does not match the reviewing node's 
IP address the reviewing node ignores the request. If 
the destination IP address does match the reviewing 
node's IP address, the reviewing node generates an 
ARP response packet like the one shown in Fig. 5. Thus, 
when node 18 checks the destination IP address of the 
request packet, it determines that it is the intended re- 
cipient and proceeds to generate an ARP response 
packet. 

Incidentally, generation of the ARP response packet 
is simplified through use of the IP protocol. In particular, 
by noting from the ARP header of the ARP request pack- 
et that the protocol is IP, the node generating the re- 
sponse packet may form the response destination offset 
(48 bits) by extracting the response source ID (16 bits) 
from the response transmitter address (64 bits). 

ARP type communication in accordance with the in- 
vention has advantages over prior ARP systems. One 
advantage is a reduced computational burden on the re- 
sponding node's CPU which results from the inclusion 
of a responding node offset address in the response 
packet. More, particularly, including the responding 
node offset address in the response packet allows the 
requesting node to acquire the responding node offset 
address, and thereafter transmit information directly to 
an application program located at the offset address. 
Thereby, allowing the responding node's CPU to be by- 
passed. 

Another advantage is the ability to accommodate 
various length ARP packets. As mentioned above, in- 
cluding the responding node offset address in the re- 
sponse packet allows the responding node's CPU to be 
relieved of having to interpret subsequently received 
packets. Therefore, packets received at the responding 
node do not need to be temporarily stored in the re- 
sponding node's CPU buffer, and the size of the packets 
that can be used is not limited by the size of CPU buffer 
(i.e. the packets do not need to fit into the CPU buffer). 
Accordingly, the invention provides greater packet 
length flexibility. 

Next, RARP type communication in accordance 
with the invention will be described. 

Figs. 6 and 7 show an illustrative RARP type re- 
quest packet in accordance with the invention and an 
illustrative RARP type response packet in accordance 
with the invention, respectively. As was the case with 
ARP type communication, RARP type communication 
may be implemented in the network of Fig. 2, using the 
address cache table of Fig. 3. The RARP type packets 
of Figs. 6 and 7 are similar to the ARP packets of Figs. 



4 and 5, respectively, and therefore only the differences 
between the respective ARP and RARP packets will be 
discussed. 

Referring to Fig. 6, it can be seen that the RARP 
request packet includes the same five primary divisions 
as the ARP request packet but differs from the ARP re- 
quest packet in three of the primary divisions. The RAM 
LLC/SNAP header division includes a resolution proto- 
col indicator (e.g. bits representing the string 0x8035) 
indicating that the type of protocol to which the request 
packet is related is RARP - rather than ARP. In addition, 
the RARP header division includes an operation indica- 
tor containing information indicating that the type of op- 
eration to which the packet is related is RARP request 
- rather than ARP request. Finally, the RARP data divi- 
sion does not include the IP address of the transmitter 
node, but rather includes some indicator that the IP ad- 
dress of the transmitter is indefinite (e.g. bits indicating 
a string of zeros). The absence of the requesting node's 
IP address is consistent with RARP operation since the 
very reason RARP requests are generated is so that the 
requesting node can determine its own IP address. 

The RARP response packet differs from the ARP 
response packet in two of the primary divisions. The 
RAM LLC/SNAP header division includes a resolution 
protocol indicator (e.g. bits representing the string 
0x8035) indicating that the type of protocol to which the 
request packet is related is RARP - rather than ARP; 
and the RARP header division includes an operation in- 
dicator containing information indicating that the type of 
operation to which the packet is related is RARP re- 
sponse - rather than ARP response. 

When a RARP type communication is initiated, a 
node which wants to determine its own IP address gen- 
erates a RARP request packet as described above. The 
RARP request is broadcast to all nodes in the network 
(e.g. the network of Fig. 2) and a node which is assigned 
to respond to RARP requests (e.g. a server) determines 
the IP address of the requesting node and generates a 
RARP response. In determining the IP address of the 
requesting node, the RARP response node first deter- 
mines the requesting nodes physical address by refer- 
encing the transmitter node's node ID as set forth in the 
RARP request's asynchronous packet header, alterna- 
tively, by referencing the transmitter node's node unique 
ID as set forth in the RARP request's data division. Once 
the requesting node's physical address has been deter- 
mined, the responding node uses its address cache ta- 
ble (e.g. the table of Fig. 3) to cross-references the re- 
questing node's physical address (node ID or unique 
node ID) with the requesting node's IP address, and in- 
serts the requesting node's IP address into the RARP 
data portion of the RARP response packet. 

Thus, for example, if node 0 of bus 0 (node 10 in 
Fig. 2) is a server, and node 1 of bus 1 (node 18) wants 
to determine its IP address : node 1 8 broadcasts a RARP 
request that includes its node unique ID ("641"). Node 
1 0 receives the request and uses the address cache ta- 
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ble of Fig. 3 to cross-references the received node 
unique ID with the IP address of node 18 ("4"). Node 10 
then inserts the determined IP address into a RARP re- 
sponse packet and transmits the response packet to 
node 18. 

An advantage of performing RARP type signaling 
in accordance with the invention is that a network imple- 
menting such signaling becomes less sensitive to bus 
resets, fn prior systems, as described above, when a 
network bus is reset the physical addresses of the nodes 
in that network may change, giving rise to incorrect 
RARP cross-references. Thus, for example, if bus 1 of 
the Fig. 2 network is reset the node ID of node 1 on bus 
-1 (node 18) may change from °1" to "3". Thereafter, if 
node 1 8 transmits a RARP request including its node ID 
of "3", and the responding node uses the table of Fig. 3 
to cross-reference the node ID, the IP address of node 
1 8 will be incorrectly determined to be V. However, the 
present invention allows IP addresses to be cross-ref- 
erenced through node unique IDs. Since node unique 
IDs do not change upon the occurrence of bus resets, 
their use in RARP cross-referencing insures correct de- 
termination of a requesting node's IP address. Thus, in 
the example, the responding node would use the cache 
table to correctly cross-reference node 18's node 
unique ID to the IP address of "4". 

While embodiments of the present invention have 
been particularly shown and described herein, it will be 
readily appreciated by those of ordinary skill in the art 
that various changes may be made without departing 
from the spirit and scope of the invention. For example, 
although the invention has been described in the context 
of IEEE-1394 communications it may be applied in the 
context of IPX communications and Apple Talk commu- 
nications. Therefore, it is intended that the appended 
claims be interpreted as including the embodiments de- 
scribed herein as well as all equivalents thereto. 

Claims 

1. A method for implementing communication over a 
network having a plurality of nodes, comprising the 
steps of: 

transmitting a request packet from a first net- 
work node to a second network node; and 
transmitting a response packet from said sec- 
ond node to said first node; 
wherein said response packet includes a phys- 
ical address and an offset address, said phys- 
ical address indicating the location within the 
network where said second node is located and 
said offset address indicating a location within 
said second node where an application pro- 
gram processes communication packets. 

2. The method according to claim 1, wherein said off- 



set address is included within a 64 bit string. 

3. The method according to claim 1 , wherein said re- 
quest packet includes a node unique ID identifying 

5 said first node. 

4. The method according to claim 1 , wherein commu- 
nications packets are processed according to the 
internet protocol. 

10 

5. The method according to claim 1 , wherein the net- 
work comprises one or more IEEE-1394 buses. 

6. The method according to claim 1 , wherein commu- 
15 nication packets received at said second node are 

passed to said location indicated by said offset ad- 
dress prior to any processing of said packets. 

7. A method for implementing communication over a 
20 network having a plurality of nodes, comprising the 

steps of: 

transmitting a request packet from a first net- 
work node to a second network node, wherein 
25 said request packet includes a node unique ID 

identifying said first node; and 
transmitting a response packet from said sec- 
ond node to said first node. 

30 8. The method according to claim 7, wherein said sec- 
ond node uses said node unique ID to determine a 
network address for said first node. 

9. The method according to claim 7, wherein said sec- 
35 ond node has an address cache table for cross-ref- 
erencing said node unique ID to one or more net- 
work addresses. 

1 0. An apparatus for implementing communication over 
40 a network having a plurality of nodes, comprising: 

means for transmitting a request packet from a 
first network node to a second network node; 
and 

45 means for transmitting a response packet from 

said second node to said first node; 
wherein said response packet includes a phys- 
ical address and an offset address, said phys- 
ical address indicating the location within the 

50 network where said second node is located and 

said offset address indicating a location within 
said second node where an application pro- 
gram processes communication packets. 

55 11. The apparatus according to claim 10, wherein said 
offset address is included within a 64 bit string. 

12. The apparatus according to claim 10, wherein said 
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15 



request packet includes a node unique ID identify- 
ing said first node. 

13. The apparatus according to claim 10, wherein com- 
munications packets are processed according to 
the internet protocol. 

14. The apparatus according to claim 10, wherein the 
network comprises one or more IEEE-1394 buses. 

1 5. The apparatus according to claim 1 0, wherein com- 
munication packets received at said second node 
are passed to said location indicated by said offset 
address prior to any processing of said packets. 

1 6. An apparatus for implementing communication over 
a network having a plurality of nodes, comprising: 

means for transmitting a request packet from a 
first network node to a second network node, 20 
wherein said request packet includes a node 
unique ID identifying said first node; and 
means for transmitting a response packet from 
said second node to said first node. 

25 

17. The apparatus according to claim 16, wherein said 
second node uses said node unique I D to determine 
a network address for said first node. 

18. The apparatus according to claim 16, wherein said 30 
second node has an address cache table for cross- 
referencing said node unique ID to one or more net- 
work addresses. 



35 



40 



45 



so 



ss 



7 



EP 0 833 485 A1 



F I G. I 



2 



C3 



ess] 



6 

1 



T 

8 




F I G. 2 



10 




NODE 




0 





24 



BRIDGE 



12 




16 


18 


\ 






\ 


NODE 




NODE 




NODE 


1 


28 


0 




1 



26 



NODE 




NODE 




NODE 


2 




2 




3 


\ 


\ 


\ 


14 


20 


22 



8 



EP 0 833 485 A1 



F I G. 3 



IP 


PHYSICAL 


ADDRESS 


NODE 

UNIQUE 

ID 


ADDRESS 


BUS ID 


NODE ID 


I 


0 


0 


I 23 


2 


I 


0 


2I3 


3 


0 


I 


456 


4 


I 


I 


64 1 


5 


0 


2 


564 


6 


I 


2 


702 


7 


I 


3 


73 I 



9 



EP 0 833 485 A1 



CO 
UJ 



UJ 

XL 
O 

£ 

CO 
IU 

S 

DT 
CL 
< 



> 
CD 

DC 

O 

u. 



X 

O 

o 



Hi 



ID 
CD 



CO 



U- 

U- 

U_ 
U. 
U. 
ti- 
ll- 
Lu 
U- 
Li_ 
x 
O 



UJ 

o 
cr 

O 
CO 



CO 
UJ 

cr 



CO 

cr 

8 

< 

111 



CO 

z 
< 



UJ 

o 



UJ 
Q 

o 
z 

or 

UJ 



CO 

z 

s 



co 



CO 

CD 
CD 

z 

X 

o 

or 
o 
cr 
cr 

UJ 



IS 
o 
z 
o 

OUJUJ 

>-os. 

CO < UJ 
<CLI 

o 
to 




o-fS 

CD 

to 



Si 

to 



10 



EP 0 833 485 A1 



IT) 
CD 



UJ 

o 

£ 

UJ 
CO 
2 

2 

q: 

Q_ 

or 



LU 
H 
>- 

m 

QL 

£ 



UJ 
Q 
O 
Z 

or 

UJ 

»- 

co 
z 
< 

or 



LU 

o 
or 

ID 

o 

CO 

UJ 
CO 

z 

£ 

CO 
UJ 

a: 



LJ 
CO 
U_ 
Ll 

O 



5 



UJ 
CO 

z 
o 

£L 
CO 
LU 

0T 



O 
O 
x 
O 

UJ 



2 

o 
o 



CO 

o 

s 

X 

o 



o 
or 

OL 

CO 
LU 

or 



o 
o 

00 

o 
o 

UJ 



0T 
CL 



LU 
CO 
2 
O 
Q_ 
CO 
LU 

or 

or 
< 

or 

I 

Q 
Z 

Ql 

o 



CO 
CO 
LU 
OT 
O 
D 
< 

UJ 



CO 



UJ 
CO 

z 

£ 
Q 

or 



UJ 
Z> 

o 



UJ 
Q 
O 



UJ 
I- 



co 



UJ 
CO 

z 
o 

CL 
CO 
LU 
QL 



CO 
CO 
UJ 
Or 
Q 
O 
< 



uj 
»- 

H 



CO 

z 

2 

I- 

LU 
CO 

z 
o 

Ql 
CO 
LU 
Or 



CO 
CO 
LU 

or 
o 
o 
< 

UJ 

o 
o 



z 

\- 
co 

LU 

s 

or 



LU 
O 



LU 
O 
O 



LU 
Q 
O 



CO 
UJ 

z> 
o 

UJ 

or 



CO 
CO 
UJ 

a: 
o 
a 
< 



UJ 

o 
o 
z 

o 



CO 

j- 
m 

<s> 
z 

x 
o 

or 



co 

UJ 

a 

or 



lu 



CO 

o 



5h- or 
wUJ 
Z*Q 
>-o< 

C0<lU 

<q:x 

o 
ro 



LU 
Q_ 



< 
UJ 

or 



U 

COLU 

o< 

_JUJ 
-IX 

<r 

to 



0T 
UJ 
Q 
Q-< 
0T LU 
<I 

CO 

ro 



0.P 

5g 

CD 

to 



CVJ 

to 



11 



EP 0 833 485 A1 



CD 



H 
LU 

X. 
O 

£ 
\- 

co 

UJ 

ID 
o 

UJ 
01 

Q_ 

q: 
< 



CO 

LU 
I- 
>- 

m 

O 



to 
x 



o 



UJ 

u. 

rO 



QQ 

\— 
</> 
<t 
o 
o 

CD 



UJ 

o 

01 
■D 

o 

0) 



t 

U- 

t 



u. 
u_ 
u. 

X 

o 



LU 

co 

u. 
o 



< 



co 

UJ 
Q 



o 
o 

X 

o 

UJ 



8 



o 

(_> 

o 
tr 

Q_ 

CO 
UJ 
01 



o 
o 

GO 

o 

X 

o 

UJ 
£L 



Q. 



I- 
co 

UJ 

o 

LU 

q: 

CL 
01 

< 

01 
01 

% 

o 

Q 

z 



CO 
CO 

Q 
Q 

< 



i 

CO 

< 



UJ 

o 



UJ 
Q 

o 



01 
UJ 

I- 



CO 

z 



co 



CO 



CO 

m 
o 



o 

UJ 

I 
o 

01 

o 
cc 

UJ 



CO 

o 



o 
ro 




<< 

CO 

ro 



12 



EP 0 833 485 A1 



I— 
ID 

O 



CO 
ID 

>- 
CD 



Q_ 

— a 

Q_ 

ce 

s 



ID £ 
CO 



U 
CO 



ID 
O 

ce 

3 

CO 

ID 

CO 

z 
o 

Q. 
CO 
ID 



ID 
CO 

z 
o 

Q_ 
CO 
ID 
CC 



O 
O 
x 
O 

ID 



O 
O 



O 
O 

P 

o 
ce 
o. 

CO 
ID 

cc 



o 
o 

CD 

o 

X 

o 

ID 
Q. 



ID 
CO 

z 

£ 

CO 
ID 
CC 

Q_ 

< 
cc 

**** 

§ 

o 

o 
z 

a: 
o 



CO 

EG 

a: 
a 
o 
< 

ID 
I- 



2 

CO 



ID 
CO 

z 

o 

CL 
CO 
ID 



ID 

o 



ID 
Q 
O 
Z 

a: 

ID 

»- 



CO 



ID 
CO 

z 
o 

Q_ 
CO 
ID 
CC 



CO 
CO 
ID 

cr 
a 
o 
< 



ID 

y— 



CO 

z 
< 

IT 

h- 

ID 
CO 

O 
CL 
CO 
ID 
CL 



CO 
CO 

u 
cc 
a 

Q 

< 

u 

Q 
O 



O 

H- 
LD 

S 

ce 



LD 
O 



LD 
O 
O 
Z 

LD 
O 
O 

z 

CD 

z 
I- 

CO 
ID 

o 

ID 

tr 



CO 
CO 
ID 

ce 
a 
a 
< 



CO 

CD 
CD 



ID 

a 
o 



CO 
LD 
Z> 

s 

ce 



ce 
o 
cc 
cc 

ID 





DC Q 
GO 

to 



13 



EP 0 833 485 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Numt>er 

EP 97 30 7025 



DOCUMENTS CONSIDERED TO BE RELEVANT 



' r 

Catagoryj 



X 



i A 



C italic: 1 ! of cocument with indication, where apcropriaie, 
oi relevant passages 



BILL CROFT (STANFORD UNIVERSITY) JOHN 
GILMORE (SUN MICROSYSTEMS): "Bootstrap 
Protoco' (BOOTPr 

NETWORK WORKING GROUP - REQUEST FOR 
COMMENTS , 

no. 951, September 1985 : XP002053146 
* the whole document * 



T. BRADLEY & C. BROWN: 
Resolution Protocol " 
NETWORK WORKING GROUP - 
COMMENTS . 

no. 1293 ; January 1992 : 
* the whole document * 



"Inverse Addess 
REQUEST FOR 
XP002053147 



Relevant 
eo ctaiir 



11-18 



11-18 



FINLAYSON. MANN . MOGUL t THEIMER (STANFORD !l-18 
UNIVERSITY): "A reverse Address 
Resolution Protocol" 

NETWORK WORKING GROUP - REQUEST FOR j 
COMMENTS. I 
no. 903. June 1984 , XP00205314S \ 
* the whole document * 



CLASSIFICATION OF THE 
APPLICATION (lnt.Cl.6) 



H04L29/00 



TECHNICAL FIELDS 
SEAFICHEO <lftt.Cl.6> 



! H04L 



he present search report has. oeen drawn up «or nti claims 



THE HAGUE 



27 January 1998 



Adkhis. F 



CATEGORv OF CITED DOCUMENTS 

X . partlCJlarty relevant n :akan aicne 

f panic Jiariy reliant \\ ;oobtr^i wrti anc tner 

-iccunvan: -A th« earns category 
A : tecnnciDgica nacKgmjnd 
O ncn wrtlton diS'Hosure 



♦•^co/ *r Dfircc-s vnaer-ying ihe invention 
carter Datant ooc;;rr.9nt but pubhsrwcj on. or 
•ifiir tha *ihng aa:? 

--io-vji >ens cited f ;-t -:thei t*.-*ncns 

"•«mHr oi ite sam* pat&ni 'airily. corresponding 



14 



